IBIS Macromodel Task Group Meeting date: 20 August 2019 Members (asterisk for those attending): ANSYS: Dan Dvorscak * Curtis Clark Cadence Design Systems: * Ambrish Varma Ken Willis * Kumar Keshavan Intel: Michael Mirmak Keysight Technologies: * Fangyi Rao * Radek Biernacki Ming Yan Stephen Slater Maziar Farahmand Mentor, A Siemens Business: * Arpad Muranyi Micron Technology: * Randy Wolff * Justin Butterfield SiSoft (Mathworks): * Walter Katz Mike LaBonte SPISim: * Wei-hsing Huang Teraspeed Labs: * Bob Ross The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - None. ------------- Review of ARs: - Walter to draft an email listing proposed clarification language related to Interconnect Models. - Done. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the August 13 meeting. Walter moved to approve the minutes. Bob seconded the motion. There were no objections. ------------- New Discussion: BIRD 197.4 discussion: Walter summarized the state of the issue. He noted that after reviewing BIRD197.4 carefully there were certain details he didn't like. He and Ambrish had each sent out alternative proposals. Walter noted that the two were quite similar, with the biggest difference being that Ambrish's removed NRZ_Threshold altogether. Walter noted that he liked the idea of removing NRZ_Threshold. He said that if a model maker wants the reference voltage to be 0.5V instead of 0.0V, they could simply subtract 0.5V from the waveform before GetWave() returns it. So, there would be no loss in functionality if we didn't have an NRZ_Threshold parameter and the EDA tool always used 0.0V as the threshold value when detecting the logic levels in the GetWave() output waveform. Ambrish noted that NRZ_Threshold was not the primary issue with his proposal, and that he had proposed separating DC_Offset and NRZ_Threshold into separate BIRDS. NRZ_Threshold could be applicable to all AMI simulations, but DC_Offset was for single-ended applications. Ambrish said the primary reason for his proposal was that his group thought BIRD197.4 was unclear and had ambiguities about what is done by the model and what is done by the EDA tool. Kumar said the flow had to be clear about who does what, and that he was confused by BIRD197.4. He said keeping it simple was better, and DDR4 and DDR5 could be handled with simpler approaches. He said that DDR6 users would be comfortable looking at differential waveforms anyway. Fangyi asked what was complex about BIRD197.4. He reviewed the primary point: Complete waveform = Rx GetWave() output + output value of DC_Offset and noted that the text makes it clear that the EDA tool adds the DC_Offset to the GetWave() output. Ambrish said it wasn't a question of understanding the text itself, it was a question of clearly dividing who does what. Ambrish noted that in BIRD197.4, if DC_Offset were an In parameter then the model had to do all the shifting (because the default "output" value of DC_Offset is 0V if DC_Offset is an In parameter), but if DC_Offset were an InOut then the EDA tool does the shifting (when it adds the value of DC_Offset to the waveform). Fangyi said the only difference between their proposals was that Ambrish wanted the default output value of DC_Offset to be the input value, while BIRD197.4 specifies the default output value as 0V. Fangyi said that with DDR5 the output waveform would usually be centered about zero, and that's why the output value of DC_Offset defaults to zero in BIRD197.4. Fangyi said it didn't make sense to have the output value of DC_Offset default to the input value, because the input and output waveforms are at two different nodes. Walter noted that he thought Fangyi's BIRD197.4 documented the process clearly, but that he didn't want to implement that process in his tool. He asked what Fangyi's proposal added relative to the simpler approach he, Ambrish and Kumar wanted. He suggested all the complications of the new parameters could instead be handled by having the model shift the waveforms so they are compared to a 0V reference. Fangyi said the benefit of the output value of DC_Offset was for the statistical flow. It allows a statistical simulation to produce an eye centered at DC_Offset. Walter said this was simply a visual aid to reference the eye to some different reference point. All that really matters is the waveform relative to the latch. The DC_Offset would just allow the final eye to correspond to a hypothetical lab measurement. Ambrish said his IP folks didn't want to follow BIRD197.4 and didn't want to output a value of DC_Offset from their models. They wanted their models to use the input value and leave the waveform the way they got it. Walter said he thought the "default" output value wasn't meaningful. If the model defines the parameter as an In, then the model is saying the "output" value is meaningless, and the waveform returned by GetWave() will be based on a 0V threshold. Kumar said the output value couldn't be determined properly at Init() time anyway, and the output value wasn't a fundamentally important quantity. Ambrish agreed that the input quantity was the important one. Walter asked why the EDA tool should add the output value to the waveform at all. He said that's only meaningful to make it comparable to the NRZ_Threshold value. Walter noted that his proposal and Ambrish's were similar, except Ambrish's removed NRZ_Threshold altogether. Walter's proposal had changed NRZ_Threshold to state that it was compared to the output of Rx GetWave(), not the "complete" waveform as in BIRD197.4. Walter shared his draft. Radek noted that the language shown went back to the ambiguous "can be added" statements, which left it unclear exactly what was added to what and by whom. Ambrish asked that people review his version and said that his clearly spelled out the division of labor. Walter made a motion to vote at the next ATM meeting on whether to introduce Ambrish's proposal as a BIRD197.5 to supersede BIRD197.4. Ambrish seconded. There were no objections to scheduling the vote. Interconnect Model syntax - questions about Aggressor_Only: Bob noted some contradictory language in the spec that had been revealed when the parser developer literally interpreted several statements. The parser developer had properly interpreted several statements, but the end result was not the intent of the spec. On page 33 of IBIS 7.0, the following statement is not literally true: No I/O pin_name in a component may appear as a Pin_I/O terminal without the Aggressor_Only column in more than one Interconnect Model in the Interconnect Model Group. This statement conflicts with the fact that a connection path only has to be tagged as Aggressor_Only at one interface, and it will be considered Aggressor_Only for the entire path. Walter noted that when an interface is tagged Aggressor_Only, it's really the connection between the interfaces that is Aggressor_Only. Bob agreed. So, only one Interconnect Model in the Model Group (or a combination of two models in the pin-to-pad and pad-to-buffer Models case) can specify the Pin's entire path without the Aggressor_Only tag appearing. But it is not necessary to have the Pin_I/O terminal itself tagged as Aggressor_Only in all the other models. They might have the Buffer_I/O terminal tagged as Aggressor_Only instead, for example. Walter and Bob agreed that the entire path is considered Aggressor_Only if any one of the *_I/O terminals is tagged Aggressor_Only (stated on page 32). Bob noted that he was going to propose a cleanup BIRD to address these issues. Bob also noted that you can't apply these rules directly to Interconnect Model Sets, because you can't check the possibilities until you know all the Sets in the Group. As an example, he noted that you might bring in Aggressor_Only tags in a Model that's part of another Set. Walter agreed this was a subtle and interesting point. Bob said he planned to finalize all the information for the parser developer in the next few days. - Walter: Motion to adjourn. - Ambrish: Second. - Arpad: Thank you all for joining. ------------- Next meeting: 27 August 2019 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives